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ABSTRACT 


Vast amounts of evolving data are created in the design of hard 
real-time software systems. This data must be managed so that it can 
be stored and retrieved according to the needs of design engineers. In 
the Computer - Aided Prototyping System (CAPS), a Design Database 
(DDB) must manage the storage and retrieval of the enthe Prototype 
System Description Language (PSDL) program. This thesis presents a 
conceptual design and initial implementation of a Design Database 
(DDB) for the Computer - Aided Prototyping System (CAPS). 
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THESIS DISCLAIMER 


Ada is a registered trademark of the United States Government, 
Ada Joint Program Office. 
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I. INTRODUCTION 


A. BACKGROUND 

The development of hard real-time and embedded software systems 

is an extremely complex and expensive process. A software 

development methodology which will reduce the development costs, 

Increase the productivity rates, and reduce the maintenance costs of 

these systems Is long overdue. The prevailing Ideas of today are 

computer-aided rapid prototyping, software reusability, and the use of 

an executable high-level specification language. The goal of the 

Computer-Aided Prototyping System (CAPS) is to integrate all of these 

Ideas and more, into one software development tool. [Ref. l:p. 66) 

In 1985, the United States Department of Defense (DOD) spent 

roughly $11 billion dollars In software costs and Is estimated to spend 

$36 billion In 1995 [Ref. 2:p. 43). The majority of these costs are 

Involved In the development and maintenance of embedded systems 

[Ref. 3:p. 13]. These costs certainly inspire one to think of software 

development In terms of a crisis. As stated by Booch: 

The i^rmptoms of the software crisis appear In the form of software 
that is nonresponslve to user needs, unreliable, excesstvefy 
expensive, untimety, inflexible, difficult to maintain, and not 
reusable [Ref. 3:p. 2]. 


4 


1 










Thus, a software development tool which can provide a 20 percent 
Improvement In software productivity will save the DOD and the 
American taxpayer billions of dollars. 


1. Hard Real-Time and Embedded Software Systems 

The development of hard real-time and embedded software 
^sterns creates additional problems In the software development 
process. As pointed out by Booch: 

I 

! 

they all generally share a set of common characteristics, namely: 

• Large. Thousands/mllllons of lines of code. 

• Long-lived. 10 to 15 years. 

• Continuous Change. Due to changing requirements. 

• Physical constraints. In target hardware address space/speed. 

• Hl^ reliability. Also fault-tolerant. p?ef. 3:p. 131 

Each of these characteristics makes embedded systems difficult to 

develop. For this reason, the DOD mandated the use of Ada in all 

embedded computer software programs, whether new programs or j 

upgrades to existing ones {Ref. 4:p. 33]. The effects of this decision on 

software development costs may not be felt Immediately , but the long 

term savings of a universal programming language for embedded 

systems will be realized. 

A hard real-time ^stem is defined as a software or firmware 
controlled system that performs all Its process functions within critical 
specified time constraints [Ref. 5:p. 3]. 
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An embedded system, on the other hand, is one that is part of a larger 
system [Ref. 3:p. 3]. However, embedded systems usuedly require hard 
real-time constraints. A real-time system is more difficult to develop 
tham a non-real-time system. As discussed in Ref. 5, some of the 
difficulties include; 

• Handling of stringent time requirements and performance 
specifications. 

• Interfacing with a real-time clock. 

• Control of hardware devices such as communication lines, 
terminals, and resources. 

• Processing of messages that arrive at irregular Intervals, with 
fluctuating input rates, and with different priorities. 

• Control of fault conditions with facilities for various degrees of 
recovery. 

• Handling of queues and buffers for storage of messages and data 
items. 

• Modeling of concurrent conditions into a proper set of concurrent 
processes. 

• Allocation and control of concurrent processes to processors. 

• Handling of communication and synchronization between 
concurrent processes. 

• Protection of data shared between concurrent processes. 

• Scheduling and dispatching (including priority handling) of 
concurrent processes. 
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Due to these demanding requirements, the development of hard 
real-time euid embedded systems Is an expensive and time consuming 
process. A development methodology which can reduce the 
development cost and time of this process will be of great benefit to 
the DOD. 

2. The Computer-Aided Prototjrping System 

The Computer-Aided Prototyping System Is one attempt to 
Improve the productivity and reliability of software through the use of 
computer-aided rapid prototyping via specification and reusable 
components [Ref. l;p. 66]. This approach to rapid prototyping uses a 
specification language called Prototype System Development Language 
(PSDL) integrated with a set of software tools [Ref. l:p. 66]. Figure 1 
gives a graphical representation of CAPS [Ref. 6:p. 8]. The major 
components of CAPS are a user Interface consisting of a syntax 
directed editor and graphical editor, a design management system 
consisting of a software base management system and design 
database, and an execution support i^stem consisting of a translator, 
dynamic scheduler, and debugger. For further explanations of the 
above systems see Refs. 6, 7, 8, 9, 10, 11, and 12. 

3. The Design Database 

Vast amounts of evolving data are created In the design of hard 
real-time software systems. Conventional database management 
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systems (DBMS) were designed for business applications and as such 
are insufficient to handle the needs of computer-aided design (CAD) 
applications. The data must be managed so that it can be stored and 
retrieved according to the needs of design engineers. In CAPS, the 
Design Database (DDB) must manage the storage and retrieval of the 
Prototype System Description Language (PSDL) program. The DDB 
must be a specialized DBMS which will store PSDL specifications in a 
hierarchical format. 
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Figure 1. Computer-Aided Prototyping System 

















4. The Object-Oriented Approach 

As stated by Ketabchl: 

There is an increasing interest in developing object-oriented 
database management systems to manage the large amoimt of data 
Involved in computer-aided design (CAD) applications [Ref. 13:p.441, 

In the past three years, several object-oriented database management 

systems have emerged. The impact of these systems on the software 

development process are just beginning to be felt. The object-oriented 

approach represents a true paradigm shift [Ref. 14:p. 386). 

B. OBJECTIVES 

The objective of this thesis is the development of a conceptual level 
design and initial implementation for the Design Database of the 
Computer-Aided Prototyping System, This design will be the basis for 
further research leading to full Implementation of the Design Database. 

C. ORGANIZATION 

Chapter II contains a survey of recent work in the area of software 
engineering databases with an emphasis on the object-oriented 
approach. An introduction to Vbase, a state of the art object-oriented 
DBMS will conclude Chapter II. Chapter III contains the actual design 
of the Design Database. Chapter IV shows the feasibility of the Design 
Database using Vbase. Conclusions and recommendations will be 
presented in Chapter V. 
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n. ENGINEERING DATABASES AND THE OBJECT-ORIENTED 

APPROACH 

A. ENGINEERING DATABASES 

There have been various attempts at achieving a solution to the 
management of design databases. According to Bendns and Ketabchl; 
Four different approaches to the solution exist: 

(1) Developing a new DBMS, called a design DBMS (DDBMS), 
equipped with facilities required in design applications. 

(2) Enhancing the current DBMSs by adding new capabilities. 

(3) Building a layer of software on top of current DBMSs to 
compensate for their deficiencies. 

(4) Using a special-purpose file manager that views the DBMS as 
an application. [Ref. 15:p. 94J 

Sherpa Data Management System provides an example of the first 
approach [Ref. 16:p. 55J. Starburst, Almaden, and Postgres provide 
examples of the second approach [Ref 16:p. 57]. The third approach is 
the most popular approach in the industry, because it allows the use 
of off-the-shelf DBMS and can be made rapidly operational 
[Ref. 15:p. 94]. With the invention of object-oriented technology, the 
first approach will become the most popular because it also allows the 
use of off-the-shelf DBMS but with enhanced capabilities. 
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B. THE OBJECT-ORIENTED APPROACH 

An object-oriented database management system (OODBMS) must 
provide persistence, concurrency, recovery, transaction management, 
authorization, and security (Ref. 16:p. 60). An OODBMS is an 
object-oriented system and as such it must also provide the following 
capabilities: 

• Objects 

• Active data 

• Abstraction 

• Extensibility [Ref. 16:p. 61] 

An OODBMS should provide application-oriented capabilities such 
as: 

• Version and configuration control for CAD applications. 

• Dynamic creation of classes. 

• Recursive classes, multiple inheritance, and extensive tool 
interface capabilities. 

• Support for multimedia objects, distributed environments, and 
graphics. (Ref. 16:p. 62] 

An object-oriented DBMS is one that supports persistency, values, an 
extensible set of data structures, an extensible set of operations, and 
abstractions [Ref. 16:p. 76]. 
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C. VBASE 


The Vbase object-oriented database management system is a 
product of Ontologic, Inc. As Ontologic puts it; 

Vbase is an object database system, providing an Integrated 

software development platform which combines the latest advances 

in compiler design and database management techniques 

[Ref. 17:p. 1]. 

The Vbase Integrated Object System is a database and 
language platform for rapidly and Inexpensive^ building 
sophisticated commercial and engineering applications 
[Ref. 17:p. 51. 

The Vbase system environment consists of the following 
components: 

• Vbase Database. Persistent objects are stored in the Vbase 
Database. 

• Object Language. Type Definition Language (TDL) is the Vbase 
data definition language. It is used to define object types in the 
database. "C" Object Processor (COP) is the Vbase data 
manipulation language. It is an object extension of Kemlghan and 
Ritchie standard C. It is used to Implement the operations of the 
object types defined using TDL. 

• System Type Library. The system type library contains many 
object ty^s which provide powerful building blocks for the 
application developer. 

• Integrated Tool Set (ITS). A single tool combining the functionality 
of a source browser, database browser, and a source debugger. 

• Object SQL. The Vbase implementation of the SQL standard query 
lai^uage. [Ref. 17:p. 6] 

Figure 2 presents a graphical representation of Vbase. 
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The steps involved In a typical Vbase database design are listed 
below; 

• Identify the objects. 

• Identify their properties as much as possible. 

• Identify the frequent operations performed on the objects. 

• Define the objects using TDL. 

• Compile and debug the TDL definition of the objects. 

• Develop COP routines to Implement the operations. 

• Compile and debug the COP programs. 

• Develop C or COP user applications. [Ref. 16:p. 8] 

Vbase is a powerful tool for implementing and maintaining large 
software applications. Its integration of compiler technology with 
database functionality in a strongly-typed i^stem provides both 
sophisticated modeling and efficient language and database 
performance. 
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m. CONCEPTUAL DESIGN FOR THE DESIGN DATABASE 


A. REQUIREBIENTS FOR THE DESIGN DATABASE IN RAPID 
PROTOTYPING 

The purpose of the Design Database (DDE) in the Computer-Aided 
Prototyping System (CAPS) is to manage the project database so that it 
can be stored and retrieved according to the needs of design engineers. 
The requirements analysis was conducted using the specification 
l8uiguage SPEC [Ref. 181. SPEC is a language for giving black-box 
specifications in the early stages of software design [Ref. 18:p. 1]. 

As stated by Berzins: 

The goal of requirements analysis is to establish the purpose of the 

proposed software system and to establish constraints and 

boundary conditions on the rest of the software development 

process [Ref. 19:p. 1-2). 

The result of the requirements anafysis should include the 
following: 

• A model of the system’s environment. 

• A description of the goals of the system and the functions it must 
perform. 

• Performance constraints on the system. 

• Constraints on the implementation of the system. 

• Resource constraints for the development project. 

• A specification of the external interfaces of the system. 

[Ref. 19:p. 2-lJ 
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1. Environment Model 

As stated by Berzins: 

The environment model must supply the concepts needed for 
describing the world in which the proposed ^stem will operate. 
These concepts consist of the types of objects in that world, the 
attributes of those objects, the relations between those objects, and 
the laws governing those objects and relations. [Ref. 19:p. 2-2] 

The environment model for the E>eslgn Database is shown 
below. The model was formulated in terms of reusable model 
components. A reusable component is a definition of a general tyi)e or 
relation [Ref. 19:p. 2-8]. The reusable components used are shown in 
Appendix A [Ref. 19:p. 2-9]. The model is expressed in a simple 
notation that is explained as it appears. Explanatoiy comments are 
preceded by a " symbol. A grammar for the notation is given in 
Appendix B [Ref. 19:p. 2-21]. 
type CAPS 

a_kind_of(software_system,CAPS) 

— The Computer-Aided Prototyping System (CAPS) is a 
-- software_system. 

type psdl 

a_kind_of[psdl,language) 

— PSDL is a language for expressing specifications. 

created_by(every psdl.a user_interface) 

— All specifications are created in the user Interface. 


13 






type design_database 

a_klnd_of(deslgn_database.software_^stem) 

— The deslgn_database is going to be a software_system. 
part_of(a design_database,every CAPS) 

— The design_database is part of CAPS 
unique(design_database) 

— There will be only one Instance of the deslgn_database for each 

— project. 

proposed(a design_database) 

— 1 am going to build a design_database. 
controls(a design_database.node) 

— The design_database controls the design data by 

— managing collections of data called nodes. 

type design.engineer 

a_kind_of(design_engineer,user) 

— The design engineer is a user of the i^stem. 
uses(every design_englneer,a user_interface) 

— The model includes only the design engineers that will interact 

— with the design_database via the user_interface. 
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type iiser_interface 

a_klnd_of[user_interface, software_^stem) 

— The user_lnterface Is a software_systeni. 
part_of[a user_interface.every CAre) 

— The user_lnterface is a part of CAPS. 
created_by(a user_interface,eveiy node) 

— The user_interface Is the only source for data, 
type data 

— any kind of data that Is used by a software system 
uses(a software_system, every data) 
relation read8(software_8ystem. data) 

" true If the data Is an Input for the software system 
reads(any software^system, any data) => uses (software_system,data) 
relation write8(8oftware_8y8tem. data) 

— true if the data is an output for the software system 
writes(any software_system, any data) => uses (software_^stem,data) 
relation updates (software.system, data) 

— true if the data is both an input and an output for the system 
updates(any software_s|ystem, any data) 

<*> reads(software_system, data) & wrltes(software_system, data) 





type node 

a_kind_of(node,data) 

— A node is the basic structure for maintaining the design database. 
needed_for(node,every specification) 

— Every specification created In the system will be stored In a node. 
created_by(every node.a user_interface) 

"All nodes are created via the user Interface. 

— The attributes of a node are listed below. 
speciflcatlon(node): psdl 
implementatlon(node); psdl 
control_constralnts(node): psdl 
graphic_record(node):graphlc_record 

— A node consists of a specification, a graphic record, 

— an implementation, and control constraints. 

text(node): psdl_file 
type graphic_record 
a_klnd_of(graphic_record, data) 
part_oflnode ,graphic_record) 

— A graphic record is one Input Into In a node. 
created_by(a user_lnterface,eveiy graphic_record) 
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t 3 rpe implementation 

a_kind_of(implementation, data) 
part_of(node.implementatlon) 

— An implementation is one input into a node. 
created_by(a user_interface.every implementation) 

type control_con8traints 
a_klnd_of(control_constraints .data) 
part_ofl[node.control_constralnts) 

-- Control constraints are part of the data in a node. 
created_by(a user_interface,every control_constralnts) 
type psdl_file 
a_klnd_of(psdl_file, data) 

— A file containing the PSDL program will be the ultimate output. 

2. High Level Goals 

The requirements for the DDB are formalized by writing a 
description of the goals of the ^stem and the functions It must 
perform in terms of the model. A major part of the requirements 
analysis is turning the informal problem statement into a precise, 
testable, and feasible set of requirements. The high level goals for the 
Design Database are showm below. 







Gl: The purpose of the system is to store the levels of a PSDL 
design in a hierarchical format. 

Gl.l: The system must allow design engineers to retrieve the 
levels for review or editing. 

G1.2: The system must be able to create and insert new levels 
into the structure. 

Gl.2.1: The system must interface with the user interface for 
inputs to the database. 

G2: The system must be able to generate the entire PSDL 

program. 

3. Constraints 

There are three types of constraints for a software system: 
Implementation, performance, and resource. The constraints for the 
Design Database are given below. 

Implementation constraints: 

Cl: The design database must be implemented with a DBMS which is 
compatible with the Sun workstation and Unix operating i^stem. 

Performance constraints: 

C2: The responses of the design database must be fast enough not to 
irritate the design engineers using the system. 
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Resource constraints: 

C3: The Design Database will be developed by thesis students at the 
Naval Postgraduate School. 

B. CONCEPTUAL MODEL OF THE DESIGN DATABASE 

The DDB Is a hierarchical storage structure for the PSDL program. 
This structure Is a tree consisting of atomic and composite nodes. 
Figure 3 Illustrates this structure. Both types of nodes contain a node 
name, a PSDL specification, an Implementation, and parent <-> child 
relationship information. An atomic node’s implementation is ADA 
code. A composite node’s implementation is graph. A graphic 
implementation may contain timing constraints In the form of control 
constreilnts. Each level of the tree Is created ty the decomposition of 
the parent node. The decomposition process is complete when all leaf 
nodes are atomic. Figures 4 and 5 present graphical representations 
of atomic and composite nodes. 


19 











Figure 3. Conceptual DDB Structure 
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C. FUNCTIONAL SPECIFICATIONS FOR THE DESIGN DATABASE 


As described by Berzins; 

A functional specification Is a precise black-box model of the 
proposed software system. The result of the functional specification 
phase is an event model of the system to be built, expressed in a 
Spec language. In the event model, computations are described In 
terms of modules, events, and messages. A module is a black box 
that interacts with other modules only by sending and receiving 
messages. An event occurs when a message Is received by a 
module at a particular Instant of time. A message is a data packet 
that is sent from one module to another. [Ref. 18:p. 2] 

A further description of the Spec language by Berzins states: 

The Spec language provides a means for specifying the behavior of 
three different types of modules: functions, state machines, and 
abstract data types. Function modules are Immutable, and 
calculate functions on data types. A machine is a module with an 
internal state. An abstract data type consists of a set of instances 
and a set of primitive operations Involving instances. [Ref. 18:p. 3] 

The functional specifications begin with a skeleton of a 
specification with places for each of the missing details to be filled in 
later. The initial specifications are shown below. 

MACHINE design_database 

-- The design database is a machine because it is time sensitive. 

INHERIT user_interface_interface 

— The system will interface with the user interface portion of the 

— CAPS system therefore, inheritance relations exist. 

STATE 

INVARIANT true 

INITIALLY true 
END 
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BiIACHINE u8er_interface 

— The user_lnterface is an external system that sends messages to 

— the design database. 

STATE 

INVARIANT true 
INITIALLY true 
END 

The next step is to make a list of the messages in each Interface 
by consulting the requirements. The user Interface is the only 
Interface for the design database. The following messages are 

produced corresponding to the goals of the system: 
user_interface_inteilace 
. create_root_node Gl. G1.2 
create_child_node Gl, G1.2 
delete_node Gl, G1.2 

lookup_node G1.1 

get_parent Gl.l 

get_child Gl.l 

traverse_tree G2 

These messages have covered all of the goals in the goal tree with the 
exception of Gl.2.1. This goal is an assumption about the 
environment. 
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The result of the user_interface Interface messages are shown below. 

MACHINE U8er_interface_interfiace 

— The skeleton specification begins by identifying the interface 

— messages. 

STATE (tree:map{node,set{node))) 

INVARIANT exlstlng_nodes(node) 

INITIALLY node = {) 

MESSAGE lookup(node_name) — Gl.l 

— Find the node requested. 

WHEN ? - node found 

REPLY node -- return node contents 
OTHERWISE REPLY EXCEPTION node does not exist 

MESSAGE get_parent(node) — Gl.l 
" Find the parent of the node requested. 

WHEN ? — parent found 
REPLY node — return parent node 
OTHERWISE REPLY EXCEPTION node is the root 
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MESSAGE get_chUd(node) - Gl.l 
— Find the child or children of the node requested. 

REPLY setinode) - retiun child node(s) 

MESSAGE create_root_node(node) — Gl.l. 01.2 

— Create a new node and insert into the top of the hierarchy 
WHEN? -- node created 

REPLY done 

TRANSITION? - add root 

MESSAGE create_child_node(node) -- Gl.l. G1.2 

— Create a new node and Insert into the hierarchy correctty 
REPLY done 

TRANSITION? - add node 

MESSAGE delete_node(node) -- Gl.l, G1.2 

— Find the node and delete it and all children from the structure. 
WHEN? — node found 

REPLY done 

TRANSITION? — remove node and children 
OTHERWISE REPLY EXCEPTION node does not exist 
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BSESSAGE traverse_tree(node) G2 

— Find the requested root node and display all children if th^r all 
” consist of PSDL specifications. 

WHEN? — node found 
REPLY setinode) 

OTHERWISE REPLY EXCEPTION psdl program does not exist 
END 


The goal of functional specification is to construct a model of the 
proposed system as it is visible to the users [Ref. 19;p. 1-3]. The 
concepts that the users will be expected to know and the details of the 
mterfaces are defined. The functional specification does not include 
any information on how the ^stem behavior is to be realized. The 
result is a set of definitions for the system concepts and Interfaces. 
The major functions of the DDE are: 

• Store the levels of a PSDL program In a hierarchical format by 
specification. 

• Retrieve the levels of a PSDL program in a hierarchical format by 
specification for review or editing. 

• Create and Insert new levels of a PSDL program in a hierarchical 
format specification. 

• Generate the entire PSDL program. 
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A brief example to illustrate the expected patterns of use of the 
methods provided by the DDB follows. To construct a prototype, the 
PSDL specihcation of the root operator is entered. At this point, the 
DDB would create a root node. Assuming the root node is composite, 
the node would be decomposed into children operators. The DDB 
would create child nodes for each decomposition. The decomposition 
process would continue until all leaf nodes are atomic. This process 
will be time consuming and the prototype will be complex. For this 
reason, the functions of retrieving nodes, parent-child relationships, 
and deleting nodes wlU be required. The tree will be traversed and the 
entire PSDL program produced once all leaf nodes are atomic. 

D. ARCHITECTURAL DESIGN 

The next step in the design process is to develop an architectural 
design. 

An architectural design is a model of the proposed system 
capturing the aspects of its behavior and structure relevant to the 
development team. The behavior of a ^stem consists of its 
interactions with other systems, while the structure of a system 
consists of its component parts and their Interconnections. 

[Ref. 19:p. 4-531 

The functional specification is a subset of the architectural design. 
The functional specification is the least detailed view of the system. 
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"The goal of the eirchltectural design is to break up the proposed 

system into a set of small modules." [Ref. 19:p. 4-54] A module is 

defined as a self contained unit of code. 

A module is both a self-contained abstraction and a unit of work. 
Modules have several different views: black-box sp>ecification, parts 
lists, glass-box specifications, and programs. [Ref. 19:p. 4-54] 

Black-box specifications are expressed in terms of the event model at 
the architectural design and functional specification stage. Hie parts 
lists contains the set of lower level modules used directly in the 
implementation. Glass-box specifications are represented by pseudo¬ 
code. Programs are produced in the Implementation phase. 

[Ref. 19:p. 4-54] The black-box specifications will be shown below. 
The parts lists and pseudo-code are not contained. Programs will be 
discussed in Chapter IV. 

Black-box specifications 
Type Node 

Model (specification implementation graphlc_record 
control_constralnts: string) 

" The following messages are used to replace the current value of 
” a node’s property with a new value. 

MESSAGE add_graphic_record(node) 

TRANSITION? — upxlate node graphic record info 
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MESSAGE add_implementation(node) 

TRANSITION? -- update node implementation Info 

MESSAGE add_8pecification(node) 

TRANSITION? — update specification info 

MESSAGE add_control_constraint8(node) 

TRANSITION? -- update control constraints 
END 


The result Is a lower level set of definitions for the system concepts 
and interfaces. These messages reveal operations on the abstract data 
type node. The lower level messages in the user_interface Interface 
are: 

add_graphlc_record 

add_implementation 

add_specification 

add_control_constralnts 

The addition of these messages creates an additional function 
requirement: 

• Create and maintain version control. 
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A new node could be created when a nodes’ properties are significantly 
changed by these low level messages. The ability w define a 
significant change will be required. TTie current implementation of the 
DDB does not address this function. Chapter IV does contain a 
discussion of version control. 

As evidenced by the functions required of the DDB. a conventional 
DBMS will not suffice. Therefore, an object-oriented DBMS will be 
used to design and implement the DDB. The object-oriented DBMS 
that will be used Is Vbase by Ontologic Incorporation. 
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IV. FEASIBILITY FOR THE DESIGN DATABASE USING VBASE 

A. EXAMPLES OF COMPONENTS IN THE DESIGN DATABASE 
1. Type Definition 

As stated earlier, the first steps in a Vbase design are to 

identify the objects, their properties, and the frequent operations 

performed on the objects. The next step is to define the objects in 

TDL. The only object in the Design Database is a Node. The 

properties of a node were defined earlier as well. The frequent 

operations are those necessary to assist in the accomplishment of the 

required functions of the design database. The TDL code below 

illustrates the definition of a Node. 

define Type Node 

supertypes » {Entity} 

properties = { 

name: String; 
specification: String; 
implementation: optional String; 
controlconstraints: optional String; 
graphicrecord: optional String; 

subNodes: distributed SetfNode] inverse $Node$isChildOf; 
isChildOf: optional Node inverse $Node$subNodes; 

} 

The main points to notice about the above definition are the 
superiypes, optional, and Inverse keywords. The supertypes 
declaration is used to show the parent class of a cype. This is used 
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for inheritance purposes. The supertype Entity is the root of all types 
in the Vbase system type library [Ref. 17:p. IX-6]. Entity specifies 
basic behavior for all object types in the system. 

The kejword optional specifies that a property need not 
necessarlfy have a value. This Indicates that a PSDL specification may 
or may not have an implementation, control constraints, or graphic 
record. The implementation property is optional due to the process 
through which PSDL specifications are created. The control 
constraints and graphic record are true optional properties in that they 
may or may not ever exist depending on whether implementation Is 
graphic or ADA. 

The inverse property sets up a system-maintained relationship 
between the property defined and its specified inverse. This property 
is used to maintain the parent-child relationship between Nodes. The 
inverse property also Illustrates the "$" notation. The "$" notation is 
used to provide a mechanism for referring to names relative to their 
scope. The symbol "$" acts as a pathname separator. 

The next step is to define the frequent operations on the object. 
The clause "operations = defines the set of operations that type 
Node will implement. The operations for a Node are buildDisplay, 
listsubNodes, llstsubNodesIntemal, and a refinement of the delete 
operation. BuildDisplay is used for output of a Node contents. 
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ListsubNodes and UstsubNodesIntemal are used to retrieve the 
children of a particular Node. The refines delete operation means the 
current definition is refining an operation already defined in the 
supertype. The actual refinement is achieved in the COP method 
which implements the operation and will be described later. The 
operations for a Node are defined as: 

operations s { 

buildDisplay (n:Node,) 
retums(Node) 

method (NodeBuildDisplay); 

listSubnodes (n:Node) 
returns (Set[Node]) 
method (NodeListSubNodes); 

llstSubnodesIntemal (n:Node. s:Set [Node]) 
returns (Set[Node] 
method (NodeListSubNodesInt); 

refines delete (n:Node) 
raises (CannotDelete) 
triggers (NodeDeleteTrigger); 


); 


The definition of a Node includes two procedure definitions: 
define Procedure Create ... end Create; 
and 

define Procedure Lookup ... end Lookup; 

Procedures differ from typed operations in that they are not tied to a 
type. For example, the operation $Node$buildDisplay can onfy be 


33 










called on instances of type Node, while the procedure $Node$Lookup 

can be called with any arguments which satisfy the argument type 

specification of the procedure. The procedure Create has an argument 

specification of the form: 

define Procedure Create 
(t:Type. 
keywords 
name: String, 
specification: String, 
optional implementation: String, 
optional controlconstraints: String, 
optional graphicrecord: String, 
optional isChildOf: Node, 
optional where: Entity, 
optional hownear: Clustering 

) 

returns (Node) 
raises (NodeAlreadyExists) 
triggers (NodeCreateTrigger) 
supertypes * {$Entity$Create); 
end Create; 

This specification gives more examples of the power of Vbase. 
Specifically, the keywords "keywords", "raises", "triggers", and 
"hownear". The keyword "keywords" specifies that the remaining 
arguments are passed by ke 3 rwords, rather than by position in the 
argument list. 

The statement "raises (NodeAlrea<fyExlsts)" specifies that the 
procedure may raise the exception NodeAlreadyExists. This exception 
is to alert the caller that the Node already exists, rather than creating 
a new copy of the Node. 
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The Create procedure also has a triggers clause, "triggers = 
(NodeCreateTtigger)". The Vbase system automatlcalfy generates a 
Create Procedure for every type defined. An explicit definition Is 
required to specify a trigger to the ^stem-defined Create. A trigger Is 
a method associated with the Invocation of a procedure or operation. 
Whenever the Create procedure Is Invoked, the trigger, 
NodeCreateTrigger, will be executed first. The trigger checks whether a 
Node already exists before creating a new one. An operation can have 
more them one trigger associated with it. The triggers are invoked in 
the order they are listed, and the last trigger must invoke the base 
method. The base method is the method which Is specified as 
implementing the operation or procedure. [Ref. 17:p. 10-11] 

The optional kejrwords where and hownear can be used In the 
Create operation to optimize disk storage of the object created to 
improve database performance. The type Clustering is an enumerated 
type with three insteinces: $area, $segment, and $chunk. Each is a 
unit of storage on the disk. Segment Is the atomic unit of transfer 
from disk to the main memory cache. To specify that an object 
created is to be stored in the same segment as some other object, the 
value of the hownear argument is "$segment" and the value of the 
where argument Is the other object. $Area and $chunk are not 
currently supported. [Ref. 17:p. IX-411 
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The second procedure defined is called Lookup. This procedure 

is used to look up a given Node, identified 1^ its Node name, in 

NodeCatalog which is a global Node catalog. The specification for 

procedure Lookup is as follows: 

define Procedure Lookup (siString) 
returns (Node) 
raises (NodeNotInCatalog) 
method (NodeLookup) 
supertjrpes s (Entity); 
end Lookup; 

There is one additional TDL definition in the DDB, 
NodesExceptlons.tdl. NodesExceptlons contains the definitions of the 
exceptions used in the application. The complete TDL definitions are 
listed in Appendix C. 

2. COP Definition 

The next step in the design of a Vbase application is to 
Implement the fi-equent operations using COP. COP is an object-based 
superset of the language C. This can be either an advantage or a 
disadvantage of Vbase, depending on the designers knowledge of the C 
language. One method Implemented for the object Node was 
"NodebuildDisplay". This operation is used to output the contents of a 
Node to a file. The COP code below implements the method: 
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#include <8tdio.h> /* include standard C routines 
#include <string.h> 

#define MAXLINE 81 /* maximum line length is 81 characters */ 

#define MAXSTRING 4000 /* maximum string length is 4000 */ 
char opname[MAXLINE]; /* declaration of local variables */ 

FILE *out; 

char spectext[AlAXSTRING]. 
imptext [MAXSTRING], 
cctext [MAXSTRING]: 

import $Type; 
import $Class; 
enter module $Node: 

method 
obj $Node 

NodeBuildDisplay(aNode) 
obj $Node aNode; 

{ 

out = fopenC'ddb.out”, "a"); 

/* convert object code to C code */ 

AM_stringToC(aNode .name .opname,sizeof(opname)); 
fprlntf(out ,"%s\n" ,opname): 

AM.stiingToCCaNode.specification, spectext, sizeof(spectext)); 
fprintf (out,"%s\n'’, spectext); 

I* determine if optional property has a value */ 

/* before executing an operation on it. */ 

if (hasvalue(aNode.implementation)) 

{ 

AM_stringToC(aNode.implementation, imptext, sizeof(imptezt)); 
fprintf[out, "%s\n", imptext); 

1 

if (hasvalue(aNode.controlconstraint8)) 

I 

AM_stringToC(aNode.controlcon8traints, cctext, sizeoftcctext)); 
fprintf(out, ”%s\n", cctext); 

) 

fclo8e(out); 

retum(aNode); 

) 
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This example helps to show the ability to interweave the 
standard C language with COP. Object code and variables are 
prefaced by the "$" symbol. Tills is used to distinguish object 
variables from standard C variables. 

The declarative statements "Import" and "enter module" are 
used for name visibility. Making a name visible provides the COP 
compiler with a reference to what the name defines. Database names 
are defined in the Vbase Kernel Database and in TDL code. Names 
defined in the Vbase Kernel Database are globally defined in a default 
set. Names not included in the default set must be made visible 
explicitly using the "import" and "enter module" statements. An 
"Import" declaration Imports the definitions of a set of database names 
so they are visible within the current COP compilation unit. An "enter 
module" declaration establishes visibility for all names defined in a 
module. (Ref. 17:p. Vll-31 

The functions "hasvalue" and "AM_strlngroC" are system 
supplied. The function "hasvalue" is used to test whether an optional 
property has a value before executing any operations on it. This is 
necessary because of the strong-typing of Vbase. The function 
"AM_stringroC" is used to convert from an object string to a standard 
C string for use by systems external to the Vbase database. 
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Two other operations defined where "NodeLlstSubNodes" and 
"NodeLlstSubNodesIntemal". These operations are used to assist in 
the traversal of the tree structure. The COP code to Implement these 
operations is shown below: 

method 

obj $SetIobj $Node] 

NodeLi8tSubNodes(aNode) 
obj $Node aNode; 

{ 

obj $Set[obj $Node] theSubNodes; 
theSubNodes s $Set[obj $Node]$Q; 
$Node$ListSubNodesIntemal(aNode, theSubNodes); 
retum(theSubNodes); 

} 

method 

obj $Set[obj $Node] 

NodeListSubNodesIntfaNode, theSubNodes) 

obj $Node aNode; 

obj $Set[obj $Nodel theSubNodes; 

{ 

obj $Node currentNode; 
iteratelcurrentNode = aNode.SubNodes) 

{ 

$Set$Insert(theSubNodes, currentNode); 
$Node$ListSubNodesIntemal(currentNode, theSubNodes); 

1 

retum(theSubNodes); 

} 

This code helps to demonstrate other powerful capabilities of Vbase. 
One is the ability of one method to invoke another method. This is 
shown in the method "NodeLlstSubNodes”. The other capabllity«ls the 
system supplied Iterator operation. This operation is used to control 
aggregate tyjies. The system defined Iterator can be modified to return 
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the aggregate in any order the user decides. 

The remaining operations and methods are listed in Appendix 
C. The above was shown to demonstrate the feasibility and power of 
Vbase. 

3. Application Programs 

The final step in a Vbase design is to develop C or COP user 
applications. The user applications developed correspond to the 
functional specifications and architectural design. The user 
applications developed in response to the functional specifications are: 

• CreateRootNode. Used to create a Node which is the root of a tree. 

• CreateChlldNode. Used to create a Node which is a child of a 
Node. 

• GetParent. Used to retrieve the name of a Node’s parent Node. 

• GetChlldren. Used to retrieve the name(s) of a Node’s child 
Node(s). 

• DeleteNode. Used to delete a Node and it’s children from the tree. 

• TraverseTree. Used to traverse the entire tree structiu^ to generate 
the PSDL program. 

The user applications developed in response to the architectural design 
are: 

• StoreProperty. Used to update, insert, or change the value of a 
Node’s property. 

• GetProperty. Used to retrieve the contents of a Node’s property. 
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The applications were all implemented using COP. They are 

shown in Appendix D. The actual code for some of these applications 

is quite long, therefore the code for TraverseTree will be shown here for 

demonstration purposes. This application takes as input the name of 

the root Node of a tree. It then iterates through the entire tree writing 

the properties of a Node to the output file "ddb.out". 

#include <stdio.h> I* include standard C routines */ 

#include <string.h> 

#define LINELENGTH 80 

#define MAXLINE 81 f* maximum linelength is 81 characters */ 
FILE *in, *out; /* local variable declarations */ 
char rootname[MAXLINE], 
tempnamepVIAXLINE]; 
import $Node; 
mainfargc. argv) 
int argc; 
char **argv; 

{ 

/* local object variables '^/ 
char ^dbname; 
char *getenv(); 

obj $Node theNode, currentNode; 
obj $Set[obj $Node] theNodes; 
obj $Str^g theRoot; 
if (argc > 1) 

{ 

dbname = argv[l]; 

} 

else if (dbname = getenv("DBNAME")) 

{ 

) 

else 

I 

printf("Must specify database name, either as a command 
line argument,\nor via the Unix environment variable 
DBNAMEXn"); 
exit(l); 

) 
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{ 

AM_databaseOpen(dbname, 0); 
in = fopenC'ddb.in", ’V); 
out s fopenf'ddb.out", "w"); 
fclo8e(out); 

^ets(tempname, LINBLENGTH, in); 

8trncpy(rootname. tempname. (8trlen(tempname) - 1)); 

theRoot = rootname; 

theNode s $Node$Lookup(theRoot); 

(void) $Node$BuildDi8play(theNode); 

theNode8 s $Node$li8tSubnode8(theNode); 
iterate(currentNode s theNodea) 

{ 

(void) $Node$BuildDi8play(cuiTentNode); 

1 

} 

protect 

AM_databa8eClose(dbname); 


The above code illustrates two additional ke3nvords: ’Void" and 
"protect". "Void" is a standard C keyword, indicating that the method 
does not return a value. The method simply outputs the information 
passed to it. 

"Protect" ensures execution of a statement when an exception is 
raised. "Protect AM_databaseClose(dbname)" ensures the database 
involved is closed in the event an exception is raised. 

4. Interface Requirements of the DDB and User Interface 

The current implementation of the DDB is Invoked 
automatically by the User Interface. The design engineer is not 
required to have any knowledge of the DDB. For example, whenever a 
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designer creates a new root Node, the User Interface will automatically 
retain the needed information and invoke the "createRootNode" 
application. The same Is true for all the other operations of the DDB. 
An excellent followup thesis to this one can concentrate on 
implementing a graphical interface between the two systems to allow 
manual and automatic operation invocation. The goal of the system 
should be to make the underlying system transparent to the user. 

Input and output between the DDB and User Interface is 
accomplished through the use of two files titled "ddb.in" and "ddb.out". 
The input format required for each application Is described below and 
is maintained by the User Interface. 

(1) Create Root Node - used to create a root node. 

Format required for ddb.in 

• node name 

• specification 

• implementation (optional) 

• control constraints (optional) 
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(2) Create Child Node - used to create a child node. 

Format required for ddb.in 

• node name 

• parent node name 

• specification 

• implementation (optional) 

• control constraints (optional) 

(3) Store Property - used to store or change a node property. 
Format required for ddb.in 

• node name 

• property 

(4) Get Property - used to retrieve a node property. 

Format required for ddb.in 

• node name 

• property name 
output to ddb.out 

• property 
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(5) Get Children - used to retrieve the names of a parent nodes 
children. 

Format required for ddb.ln 

• parent node name 
output to ddb.out 

• child node(s) names 

(6) Get Parent - used to retrieve the name of a child nodes parent. 
Format required for ddb.in 

• child node name 

output to standard output device 

• parent node name 

(7) Delete Node - used to delete a node and all of it’s children. 
Format required for ddb.in 

• node name to delete 

(8) Traverse Tree - used to traverse the entire tree and produce the 
psdl program. 

Format required for ddb.in 

• root node name 
output to ddb.Out 

• entire psdl program 
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5. Version Control 


The version control function has not been addressed to date. 
The previous functions were Implemented without concern for version 
control. However, the issue of version control Is an important one and 
must be addressed in future Implementations. 

A pre-release article from Ontologic, Inc. describes a history 
mechanism embedded into the Vbase Object Manager [Ref. 20:p. IJ. 
However, this feature has not been implemented in current releases. 
A discussion of the key points raised in the article will be helpful to 
further explain the issue of version control. Hopefully, future Vbase 
releases will Incorporate this feature. 

There are two basic approaches to version control: linear and 
non-linear evolution. Linear evolution is a series of states through 
which an entity passes as it is mutated (Ref. 20:p. 1). A version is a 
snapshot of the entity at a point in time. The whole set of versions, 
called its Version-Set, represents the entire history of an entity [Ref. 
20:p. 2]. Figure 6 gives a graphical representation of the Version-Set. 

V: {vl —>v2 —>v3 ”>v4} 

Figure 6. Version Set 

Non-linear evolution is defined as a situation in which a version 
has more than one successor or more than one predecessor version 
[Ref. 20:p. 5]. In order to correctly maintain these relationships, there 
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must be a method to describe the default path from a version. The 
other required method is to describe alternatives to the default path. 
The system must resolve a simple reference by default to the most 
recent version in a linear evolution path, and to the default branch of 
a forking evolution path, so simple references are unambiguous 
[Ref. 20:p. 5]. 

There are two ways to make a new version: manually or 
automatically. Manual version creation can be invoked by the user 
whenever he thinks that a significant change has occurred. Automatic 
version creation is invoked without the intervention of the user 
[Ref. 20:p. 3]. This is controlled by the type of the entity via its 
property and operations definitions. 

In addition to the PSDL components of a Node, there must be 
audit trail information stored in the Node for version control. The 
current implementation of the DDE does not include audit trail 
information. The recommended audit trail information to be used in 
future implementations is given in Figure 7. 

As previously stated, a system supplied version mechanism is 
not implemented in current release versions. The set of tools required 
to implement version control are within Vbase and could be 
implemented by the designer. This would be another excellent 
followup thesis to this one. 
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PROJECT NAME 


RESPONSIBLE ENGINEER 


WHEN CREATED 


WHEN LAST UPDATED 


VERSION NUMBER 


CURRENT VERSION 


Figure 7. Audit Trail Properties 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. SUMMARY AND CONCLUSIONS 

The development of hard, real-time software systems continues to 
be an expensive process for the DOD. The Computer-Aided 
Prototyping System (CAPS) is one tool under development which will 
help to decrease the costs of these systems. CAPS is an attempt to 
integrate several of the prevailing software development methodologies 
into one tool. With a central theme of rapid prototyping, CAPS shows 
great promise for the future of software development in the DOD. 

This thesis concentrated on the development of the Design 
Database (DDE) for CAPS. It is a key element of the system as project 
management has become an issue of increasing importance in software 
development. A robust Design Database which can efficiently and 
effectively, store and retrieve the Prototype System Description 
Language (PSDL) program will significantly contribute to the overall 
success of CAPS. 

The goal of this thesis has been to develop a conceptual level 
design and initial implementation of the Design Database for CAPS. 
The basic design was developed using the object-oriented approach 
and the initial implementation was accomplished with an object- 
oriented DBMS (Vbase). Object-oriented technology offers several 
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enhancements to current DBMS technology, and with its maturity it 
will become as important to CAD applications as relational database 
technology has become to business applications. This study has 
accomplished the goals of the thesis and identified key aspects of the 
design Database for continued implementation and follow-up thesis 
work. 

B. RECOMMENDATIONS FOR FURTHER RESEARCH 

This thesis has provided a foundation for further implementation of 
the Design Database. Further research and testing is required to 
complete full implementation of the system and to identify potential 
weaknesses. This author recommends work in the following specific 
areas: 

• The design and implementation of version control within the design 
database. The issue of version control is an important one and 
must become an Integral part of the DDB if it is to become an 
effective part of CAPS. 

• The design and implementation of a graphical Interface between the 
User Interface and the remainder of CAPS. Without an effective 
User Interface, CAPS will find little usefulness in the "real world". 

• The study of memory management for the DDB as well as the 
entire system. Each application in Vbase requires two megabytes 
of memory. With the DDB and the SBMS both implemented in 
Vbase, the memory requirements for these two systems alone will 
be immense. 

• The design and Implementation of an efficient method for 
constraint checking within the various levels of decomposition. 
Currently, the User Interface is maintaining minimal Information 
for this purpose but a more elaborate ^stem is required. 
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APPENDIX A 


REUSABLE COMPONENTS LIBRARY 

The model was formulated In terms of reusable components for 
business applications. The reusable component library used is shown 
below as taken from Ref. 19. Explanatory comments extend from the 
leftmost " to the end of the line. 

relation is_a(object,type) 

— Means the object is an Instance of the type. 
is_a(every object,a type) 

— Every object is an instance of some type. 

relation a_kind_of(type,type) 
a_kind_of[any type 1.any type2) <=> 

(is_a(any object, type 1) => is_a(obJect,typ)e2)) 

— a_kind_ofttypel,type2) means typel is a subset of type2. 

type object 

a_kind_of(any type,object) 

-- Any type is a subset of the universal type "object", 
type type 

" The set of all types. 

is_a(an object 1,any obJect2) <=> ls_a(obJect2,type) 

" Any object with instances is a and all ^T)es are non-empty. 

type relation 

— The set of all relations. 

~(ls_a(any object,^^) & is_a(obJect,relation)) 

” Types and relations do not overlap. 

relation unlque(type) 

" Means there is only one instance of the tyi)e. 
unlque(any type) <■> 

ls_a(any object 1,type) & is_a(any obJect2,type) «> equal(obJectl,obJect2) 
type software_system 

“ The set of systems to be realized as programs. 

relation proposed(software_system) 

Means the software system is going to be developed. 
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relation eontrols(software_^stem,type) 

— Means the instances of the type are created, modified, and 

— destroyed onfy by means of the software system. 

type agent 

— The cause of an activity, usualfy a person or organization, 
type activity 

” The set of all processes and actions, 
type user 

a_kind_of(user,agent) 

“ A class of users of a software_system. 
uses(every user,a sofiware_system) 

relation uses(user,software_itystem) 

— Means the user depends on the software_system to achieve some 

— goals. 

relation malntalns(user,type) 

— Means the Instances of the type are created, modified, or 

— destroyed upon request from the user. 

maintains(any user,any type) & controls(any software_system,type) => 
uses(user,software_system) 

type supplier 
a_kind_of(suppller,agent) 
supplies(eveiy suppUer.an object) 

type vendor 

a_kind_of[vendor, supplier) 
sells(every vendor,a product) 

type customer 
a_kind_of(customer,agent) 
buys(eveiy customer,a product) 

relation buys(customer,object) 

” Means the customer buys Instances of the object. 
buys(any customer,any object) ■> buys_from(customer,object,a vendor) 

relation buys_from(customer,object,vendor) 

— Means the customer buys the object from the vendor. 
buys_from(any customer,any object,any vendor) «> 

pays(customer,vendor) 
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relation pays(customer.vendor) 

" Means the customer sends money to the vendor. 

relation supplles(supplier,object) 

— Means the supplier creates and delivers Instances of the object. 

relation sells(vendor.object) 

— Means the vendor sells instances of the object. 
sells(any vendor.any object) ■> supplles(vendor,object) 

" To sell something, a vendor must supply It. 
sells(any vendor.any object) => buys(a customer.object) 

— To sell something, someone must buy It. 

relation needed_for(object.actlvity) 

— Means an instance of the object is needed for the activity to occur. 

relation wants(agent.object) 

“ Means the agent is motivated to acquire the object. 
wants(any agent.any activity) & needed_for(any object.activity) => 
wants(agent.object) 

— People want the means to achieve their ends. 
wants(any customer.any object) => buys(customer.object) 

— Customers are agents with the resources to satisfy their wishes. 
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APPENDIX B 


MODEL LANGUAGE GRAMMAR 

The grammar for the Model language used In the requirements 

analysis is shown below as taken from Ref. 19. Terminal symbols 

appear in double quotes. Repetitions are Indicated by x* (zero or more 

x’s) or x+ (one or more x’s). Alternatives are separated by vertical 

bars. Ranges of single character alternatives are shown (0-21 

(meaning "0" I "1" I "2"). 

model = (type 1 relation)* 

type = "type" name law* attribute* 

relation = "relation" name "("name_llst")" law* 

attribute = name "("name_llst")" ":" name 

law = relationship I law I law op law I "(" law ")" 

relationship = name "(" arg_list")" 

op = "&" I " I" I "=>" I "<=>" 

name_Ust = name ("," name)* 

arg_llst = arg ("," arg)* 

arg = variable I attrlbute_value 

variable = prefix name digit* dependency 

attribute_value = arg name dependency 

prefix = "a" I "an" I "every" I "any" I "" 

dependency = "("arg_Ust")" I "" 

name = alpha+ ("_" alpha+)* 
alpha = (a-z) I (A-Z) 
digit = (0-91 

All ops are left associative: a op b op c means (a op b) op c. 

Precedence order: (strongest) I, ■>, <=> (weakest). 

Comments extend from the leftmost " to the end of the line. 
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APPENDIX C 


TDL DEFINITION EXAMPLES 

The TDL definitions have all been successful^ compiled and tested. 
Testing consisted of actual operation of the Design Database using an 
example prototype. The tests were conducted by invoking each 
application or operation with the correct format in the input file 
"ddb.in". All exception definitions were tested by Intentionally invoking 
each operation. 

Node definition 
define Type Node 
supertypes = {Entity}: 

properties = 

{ 

name: String: 
specification: String: 
implementation: optional String: 
controlconstraints: optional String: 
graphlcrecord; optional String; 

subNodes: distributed Set[Nodel inverse $Node$isChildOf: 
isChlldOf: optional Node inverse $Node$subNodes: 

I; 


operations = 

{ 

buildDlsplay (n:Node) 
retums(Node) 

method (NodeBuildDlsplay); 

listSubnodes (n:Node) 
returns (Set[Node]) 
method (NodeLlstSubNodes); 

listSubnodeslntemal (n:Node,s:Set[Node]) 
returns (SetfNode)) 
method (NodeLlstSubNodesInt); 
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refines delete (n; Node) 
raises (CannotDelete) 
trlggers(NodeDeleteTrigger); 


define Procedure Create 

(t:Type. 

keywords 
name: String, 
specification: String, 
optional Implementation: String, 
optional controlconstralnts: String, 
optional graphlcrecord: String, 
optional IsChlldOf: Node, 
optional where: Entity, 
optional hownear: Clustering) 

returns (Node) 

raises (NodeAlreadyExlsts) 

triggers (NodeCreateTlrtgger) 

supertypes = {$Entity$Create); 
end Create: 

define Procedure Lookup (s:Strlng) 
returns (Node) 
raises (NodeNotInCatalog) 
method (NodeLookup) 
supertypes * {Entity): 
end Lookup: 

end Node: 

define UnorderedDictionary NodeCatalog 
memberspec = Node: 

IndexSpec = String; 
end NodeCatalog: 

define Variable NodeCatalogVar: UnorderedDlctlonaryfNode, Strlngl 
NodeCatalog: 

define variable NodeSerialNumber: Integer 1; 
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Exception definitions 

define ExceptionType NodeExceptlon 

supertypes = {Exception}; 
properties = 

I 

nodeName; String: 

I; 

end NodeExceptlon; 

define ExceptionType NodeNotInCatalog 

supertypes = (NodeExceptlon); 
end NodeNotInCatalog; 

define ExceptionType NodeAlreadyExlsts 

supertypes = (NodeExceptlon); 
end NodeAlreadyExlsts; 
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APPENDIX D 


COP OPERATIONS CODE 

The COP definitions have all been successfully compiled and 
tested. Testing consisted of actual operation of the Design Database 
using an example prototype. The tests were conducted Invoking 
each operation with the correct format in the input file "ddb.in". All 
exception definitions were tested by intentionally Invoking each 
operation. 

String Definitions 

/* This file contains all the symbolic constant definitions used */ 

/* in the COP operation and application programs */ 

#define LINELENGTH 80 /* Linelength is 80 characters */ 

#deflne MAXLINE 81 /* Maximum linelength is 81 characters */ 

/• Including the null (\0) character */ 

#define LINEBUFFER 82 /• Temporary buffer used to hold Maxline •/ 
#define MAXSTRING 4000 /* Maximum length of a String in Vbase •/ 

Node Methods 

/• Program - Node.c */ 

/* This program implements the methods defined in Node.tdl */ 

/* The methods implemented are •/ 


/• Node Build Display •/ 

/• Node List SubNodes */ 

/* Node List SubNodes Internal */ 
/* Node Lookup •/ 

/* Node Create Trigger */ 

/* Node Delete Trigger •/ 


#include <stdio.h> /* include standard C routines */ 
#include <string.h> 

#lnclude "strlng.def /* include string definitions file */ 
char opn8une[MAXLINE]; /* Local variable declarations */ 
FILE *out; 

char spectextfMAXSTRINGJ, 
imptext[MAXSTRINGl, 
cctextIMAXSTRING]; 
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import $Type; 
import $Class: 

enter module $Node; 

method 
obj $Node 

NodeBuildDisplay(aNode) 

obJ $Node aNode; 

{ 

out = fopenC'ddb.out", "a"); 


/• Convert Object Code to C Code */ 

AM_stringToC(aNode.name.opname.sizeof[opname)): 

fiprintf(out,"%s\n",opname); 

AM_strln^oC(aNode.specijfication.spectext,sizeofIspectext)); 
fprintf (out."%s\n", spectext); 


if (hasvalue(aNode.implementation)) 

I 

AM_stringToC(aNode.impIementation, imptext, sizeof(imptext)); 
fprintfl[out, "%s\n", imptext); 

} 

if (hasvalue(aNode.controlconstralnts)) 

I 

AM_stringToC(aNode.controlconstraints, cctext, slzeof(cctext)): 
fprintflout, "%s\n", cctext): 

1 

fclose(out): 

retum(aNode): 


method 

obj $Set[obj $Nodel 
NodeListSubNodes(aNode) 
obj $Node aNode: 

{ 

obj $SetIobj $Node] theSubNodes; 
theSubNodes = $Set(obj $Node]$[i; 
$Node$ListSubNodesIntemal(aNode, theSubNodes): 
retum(theSubNodes): 
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method 

obj $Set[obJ $Node] 

NodeLlstSubNodesInt(aNode, theSubNodes) 

obJ $Node aNode; 

obj $SetlobJ $Node] theSubNodes; 

I 

obj $Node currentNode; 
lterate(cuiTentNode = aNode.SubNodes) 

I 

$Set$Insert(theSubNodes, currentNode); 
$Node$LlstSubNodesIntemal(currentNode, theSubNodes); 

) 

retum(theSubNodes); 


method 
obj $Node 

NodeLookupCaNodeNsune) 
obj $String aiNodeName; 

{ 

obj $Node theNode; 
theNode = 

$UnorderedDictlonary$GetElement($NodeCatalogVar,aNodeName); 
except(enf: ElementNotFound) 
i 

raise NodeNotInCatalog(nodeName: aNodeName); 

} 

retum(theNode): 

I 

method 
obj $Node 

NodeCreateTrlgger(aType, name, specification, implementation, 
controlconstraints, graphicrecord. 
isChildOf. where, hownear) 

obj $Type aiype; 
keyword obj $String name; 
keyword obj $String specification; 
keyword obj $String implementation; 
ke 5 rword obj $String controlconstraints; 
ke 3 nvord obj $String graphicrecord; 
keyword obj $Node isChildOf; 
keyword obj $Entity where; 
ke 3 nvord obj $Clustering hownear; 
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{ 

obj $Node theNode; 

{ 

theNode = $Node$Lookup(name); 

raise NodeAlreadyExlsts(nodename:name); 


} 

except (nnc: NodeNotlnCatalo^ 

{ 

theNode = $$(a'iype, namername, speciflcation:speciflcation, 
Implementatlon.'implementation. 
controlconstraints:controlconstraints, 
graphicrecordigraphicrecord. 
isChildOfrlsChildOf. 
where.'where, hownearrhownear); 

$UnorderedDictlonar 5 r$Insert($NodeCatalogVar,name,theNode); 

retum(theNode): 

1 

} 

method 

void 

NodeDeleteTrlgger(aNode) 

obJ $Node aNode; 

{ 

obj $Node theNode; 
lterate(theNode = aNode. subNodes) 

$UnorderedDictionary$Remove($NodeCatalogVar,theNode.name); 

$$(aNode); 

} 
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APPENDIX E 


APPLICATION PROGRAMS 

The application programs have all been successfully complied and 
tested. Testing consisted of actual operation of the Design Database 
using an example prototype. The tests were conducted by invoking 
each application or operation with the correct format in the input file 
"ddb.in". All exception definitions were tested by intentionally invoking 
each operation. 


Create Root Node 

/* Program CreateRootNode */ 

/* This program is used to create a Node which will be the root of */ 
/* a tree structure. It interfaces with the User Interface through */ 

/* a file called ddb.in. */ 

/• The program reads in the required information from ddb.in */ 
/* then creates the Node and Inserts it as the root node */ 

/* The required information in ddb.in is */ 

/* Node Name •/ 

/* Specification •/ 

/• Implementation (Optional) */ 

/* Control Constraints (Optional) •/ 

#include <stdio.h> /* include Standard C routines •/ 

#lnclude <string.h> 

#include "string, def /* include string definitions file */ 

/* Local variable declarations */ 
char tempnamelMAXLINE], 
opname(MA^INEJ, 
templinelMAXLINEJ, 
tempgrlMAXLINE]; 

char TemptextlLINEBUFFEiy, 

Graphtext[LINEBUFFERJ; 

char SpectextfMAXSTRING], 

ImptextIMAXSTRING], 

CctextfMAXSTRING]. 

GrlinklMAXSTRINGl; 
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FILE *ln. ‘gr: 
Int linelength; 
int i; 

Import $Node; 


main (argc, argv) 

Int argc; 
char **argv: 

I 

char *dbname; 
char *getenvO; 

obj $Node theNode; /* local object variables */ 
obj $Strlng thename. 
thespec, 
thelmp, 
thecc, 
thegraph; 

if (argc > 1) 

{ 

dbname = argv(l]: 

) 

else if (dbname = getenv("DBNAME”)) 

I 

} 

else 

I 

printfC'Must specify database name, either as a command line 
argument,\nor via the Unix environment variable DBNAMEXn"); 
exlt(l); 

} 

{ 

AM_databaseOpen (dbname, 0); 
in e fopenC'ddb.in", "r"); 

fgets(tempname, LINELENGTH, in); /• Read the name of the Node */ 
stmcpy(opname, tempname, (strlen(tempname) - 1)); 
fgets(templlne, LINELENGTH, in); /• Read first property */ 
if (stmcmpCSPECIFICAnON", templine, 13) -« 0) 

/• Verify Specification is first Property */ 

I 

stmcpy(Spectext,templine, strlen(templine)); 

strcat(Spectext, "\n"); 

templine[0] = ’\0’; 

for(i » 0: i < MAXLINE; i++) 

Temptextli) * ’\0’; 
fgets(templine, LINELENGTH, in); 
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whlle(stmcmp("IMPLEMENTA'nON".templlne, 14) l» 0) 

/* Read in Specification Until Implementation Begins */ 

I 

stmcpy(Temptext, templine,strlen(templine)); 

strcat(Temptext, "\n"); 

strcat(Spectext, Temptext); 

templinelO] = ’\0’; 

for(i « 0; i < MAXLINE; 1++) 

Temptext[i] = ’\0’; 
fgets(templlne, LINELENGTH, in); 

} 

Cctext[0] = ’\0’; 

Grlink[0] = ’\0’; 

stmcpy(Temptext. templine, strlen(templine)); 
strcat(Temptext. "\n"): 
strcat(Imptext, Temptext); 
templlne[01 = ‘\0’; 

for(i a 0; i < MAXLINE; i++) 

Temptext[I] = ’\0’; 
fgets(templlne. LINELENGTH, in); 

/• If Implementation is graph then read in graphic record */ 

if (stmcmpC'GRAPH", templine, 5) == 0) 

I 

gr a fopenC'links.c", "r"); 
fgets(tempgr, LINELENGTH, gr); 
while (feofigr) == 0) 

{ 

stmcpy(Graphtext, tempgr, strlen(tempgr)); 

strcat(Graphtext, "\n"); 

strcat(Grllnk, Graphtext); 

tempgrIO] = ’\0'; 

for (i = 0; i < MAXLINE; 1++) 

Graphtextli] * ’\0’; 
fgets(tempgr, LINELENGTH, gr); 

} 

) 

fclose(gr); 

stmcpy(Temptext, templine, strlen(templlne)); 

strcat(Temptext, "\n"); 

strcatfimptext, Temptext); 

templinelO] = ’\0’; 

for (i = 0: i < MAXLINE; i++) 

TemptextUI = ’\0’; 
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while (feoflin) == 0) 


fgets(templine. LINELENGTH, in); 
if(stmcmp("CONTROL CONSTRAINTS", templine, 19) 
I* Read in Control Constraints */ 

{ 

while(feof(in) == 0) 

{ 

stmcpyfTemptext. templine, strlen(templine)); 

strcat(Temptext. "\n"); 

strcat(Cctext, Temptext); 

templine[0] = ’\0’; 

for (i =0; i < MAXLINE; i++) 

Temptext[ll = ’\0’; 
fgets(templlne. LINELENGTH, In); 

1 

} 

else 

/* Read in Implementation */ 

I 

stmcpy(Temptext, templine, strlen(templine)); 

strcat(Temptext, "\n"); 

strcat(Imptext, Temptext); 

templlnelO) « ’\0’; 

for (i = 0; i < MAXLINE; i++) 

TemptextUl = '\0’; 
fgets(templine, LINELENGTH. in); 


1 

else 

I 

printf["Input file is not in the correct format."); 
exit(l); 

} 

fclose(in); 

/* Assign C variables to Object Variables •/ 
thename = opname; 
thespec = Spectext; 
theimp = Imptext; 

/* Execute Create depending on the properties */ 
if ((strlen(Cctext) == 0) && (strlen(Grlink) 0)) 

{ 

theNode » $Node$[name:thename,8pecification:thespec, 
implementation.'thelmp]; 
except(nae:NodeAlreadyExists) 


65 






theNode = $Node$Lookup(thename); 

) 

I 

else if ((strlen(Cctext) == 0) && (strlen(Grllnk) 1= 0)) 

{ 

thegraph = Grllnk; 

theNode s $Node$[name:thename. specificatlon:thespec. 

implementation:thelrnp, graphicrecord: thegraph]; 
except(nae:NodeAlreadyExists) 

1 

theNode = $Node$Lookup(thename); 


else 

{ 

thecc = Cctext; 

theNode = $Node$[n£une:thename, specification:thespec, 
implementation:theimp, controlconstralnts:thecc]; 
except(nae:NodeAlreadyExlsts) 

I 

theNode = $Node$Lookup(thename); 

) 

) 

} 

protect 

AM_databaseClose(dbname); 


Create Child Node 

/* Program Create Child Node •/ 

/* This program is used to create a Node which will a child of •/ 
/* a node in the tree structure. It interfaces with the User */ 

/* Interface through a file called ddb.ln. •/ 

/• The program reads in the required information from ddb.ln •/ 
/* then creates the Node and Inserts In the proper order •/ 

/* The required Information In ddb.ln Is •/ 


I* Node Name •/ 

/• Parent Node Name •/ 

/• Specification •/ 

/• Implementation (Optional) •/ 

/* Control Constraints (Optional) •/ 
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#include <stdio.h> /* include standard C routines */ 
#tnclude <strlng.h> 

#include "string.def /* include string definitions file */ 
/* local variables */ 
char tempname[MAXLINEJ, 
opname[MA:^INE]. 
templlne[MAXLINE j, 
tempgrIMAXLINEl; 
char tempparent[MA3<LINEJ, 
parentnamelMAXLINE], 

char TemptextlLINEBUFFERJ. 

GraphtejctlLINEBUFFER]; 

char SpectextlMAXSTRING], 

ImptextlMAXSTRING], 

CctexttMAXSTRING]. 

Grllnk[MAXSTRING]; 

FILE *in, ‘gr; 
int Unelength; 
int i; 

import $Node: 
main (argc, argv) 

int argc; 
char •*argv: 

{ 

char *dbname; 
char *getenv(); 

obj $Node theNode, 

parentNode; /• local object Variables */ 

obj $String thename, 
thespec, 
theimp, 
thecc, 
thegraph, 
theparent; 

If (argc > 1) 

I 

dbname = argv[l]; 

I 

else if (dbname = getenv("DBNAME")) 
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I 

else 

{ 

printfC'Must specify database name, either as a command line 
argument,\nor via the Unix environment variable DBNAMEXn"); 
exlt(l): 

} 

{ 

AM_databaseOp)en (dbname, 0); 
in = fopenC'ddb.ln", "r"); 

fgets(tempname, LINELENGTH, in); /* Read the name of the Node •/ 
stmcpy(opname, tempname, (strlen(tempname) - 1)): 
fgets(tempparent, LINELENGTH, in); /* Read the parent Node name */ 

stmcpy(parentname, tempparent, {strlen(tempparent) - 1)); 
fgets(templlne, LINELENGTH, in); /* Read in the property */ 

/• Verify Specification is first Properfy •/ 
if (stmcmpC'SPECIFICATION", templine, 13) == 0) 

{ 

stmcpy(Spectext,templine, strlen(templlne)); 

strcat(Spectext, "\n"); 

templlnelO] = ’\0’; 

for(i = 0; i < MAXLINE; i++) 

TemptextW = ’\0’; 
fgets(templine, LINELENGTH, in); 

whlle(stmcmp("IMPLEMENTATION",templine, 14) != 0) 

/* Read in Specification Until Implementation Begins */ 

{ 

stmcpy(Temptext, templine.strlen(templlne)); 

strcat(Temptext, "\n"); 

strcat(Spectext, Temptext); 

templine[0J = AO’; 

for(i = 0; i < MAXLINE; i++) 

TemptextllJ = ’\0’; 
fgets(templine, LINELENGTH, in); 

1 

CctextlOJ = ’\0'; 

GrlinklOl = ’\0’; 

stmcpy(Temptext, templine, strlen(templlne)); 

strcat(Temptext, 'An"); 

strcat(Imptext, Temptext); 

templlne[OI = '\0’; 

ford = 0: i < MAXLINE; 1++) 

Temptext[i] = '\0’; 
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/• If Implementation is graph then read in graphic record */ 
fgets(templine, LINELENGTH, in); 
if (stmcmpC'GRAPH", templhie, 5) == 0) 

{ 

gr = fopenC'links.c", "r"); 
fgets(tempgr, LINELENGTH, gr); 
while (feoflgr) ■** 0) 

{ 

stmcp 5 r(Graphtext. tempgr, strlen(tempgr)); 

strcat(Graphtext, "\n"); 

strcat(Grllnk,Graphte3rt); 

tempgr[0] = ’\0‘: 

for (1 - 0; 1 < MAXLINE: 1++) 

Graphtext[il = ’\0’: 
fgets(tempgr. LINELENGTH, gr); 

I 

) 

fclose (gr); 

stmcpyfTemptext, templine, strlen(templine)); 

strcat(Temptext, "\n"); 

strcat(Imptext, Temptext); 

templlne[01 = ’\0’; 

for (i = 0; i < MAXLINE; i++) 

Temptextli] = ’\0’; 

while (feof(in) == 0) 

I 

fgetsltempline, LINELENGTH, in); 
iflstmcmpC'CONTROL CONSTRAINTS", tempUne, 19) *= 
/* Read in Control Constraints */ 

{ 

while(feof(ln) == 0) 

I 

stmcpy(Temptext, templine, strlen(templine)); 

strcat(Temptext, "\n"); 

templlne(0] = ’\0’; 

for (i =0; i < MAXLINE; i++) 

Temptextli) » ’\0’; 
fgets(templine, LINELENGTH, in); 

) 

) 

else 

{ 

StmcpyfTemptext, tempUne, strlen(templlne)); 
strcat{Temptext, "\n"); 
strcat(Imptext, Temptext); 
templine(0] = ’\0’; 
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for (1 * 0; i < MAXLINE; i++) 

Temptext[l] = ’\0’: 

) 

I 

) 

else 

{ 

printfC'Input file is not in the correct format."); 
exit(l); 

} 

fclose(in); 

/• Assign C variables to Object Variables •/ 

theparent = parentname; 

thename = opname; 

thespec » Spectext; 

thelmp = Imptext; 

parentNode = $Node$Lookup(theparent); 

/* Execute Create depending on the properties */ 
if ((strlen(Cctext) == 0) && (strlen(Grllnk) 0)) 

I 

theNode = $Node$Iname:thename.specificatlon:thespec, 

Implementatlonrthelmp, isChildOfrparentNode]; 
except(nae:NodeAireadyExists) 


{ 

theNode = $Node$Lookup(thename); 

} 

} 

else lf[(strlen(Cctext) == 0) && (strlen(Grlink) 1= 0)) 

{ 

thegraph = Grllnk; 

theNode = $Node$[name:thename, specificatlonithespec, 
lmplementatlon:theimp. graphlcrecord:thegraph, 
isChildOf:parentNodel; 
except(nae: NodeAlreadyExlsts) 

{ 

theNode = $Node$Lookup(thename); 

} 

I 

else 

I 

thecc = Cctext; 

theNode = $Node$[name:thename, speciflcatlon:thespec, 
implementatlon:thelmp, controlconstraintsrthecc. 
isChildOfrparentNode]; 
except(nae:NodeAlreadyExists) 


theNode = $Node$Lookup(thename); 
I 

} 

) 

protect 

AM_databaseClose(dbname); 


Store Property 

/* Program Store Property */ 

/* This program is used to store or change a Node property. */ 
/* It interfaces with the User Interface through a file caUed •/ 

/* ddb.in. •/ 

/* The program reads in the required Information from ddb.in */ 
/* then inserts the new property into the Node */ 

/* The required information in ddb.in is •/ 

/* Node Name */ 

/* Property Name */ 

#lnclude <stdlo.h> /* Include standard C routines */ 

#include <string.h> 

#include "string.def /* include string definitions file •/ 

/* local variables •/ 
char opname[MAXLlNEl, 
tempnamelMAXLlNEl, 
templine[MAXLINE]; 

char nodepropertylMAXSTRINGl; 
char temptextILINEBUFFERI: 

FILE *in; 

Int i; 

import $Node; 

mainleirgc, argv) 

int argc; 
char **argv; 


char *dbname; 
char *getenvO: 

obj $Node theNode; /• local object variables •/ 
obj $Strlng theOperator, 
theProperty; 
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if (argc > 1) 

{ 

dbname = argv[ll; 

} 

else if (dbname = getenv("DBNAME")) 

{ 

} 

else 

{ 

printfC'Must specify database name, either as a command line 
argument, \nor via the unix environment variable command"): 
exlt(l); 

I 

{ 

AM_databaseOpen (dbname, 0); 
in = fopenC'ddb.in", "r"); 

fgets(tempname, LINELENGTH, in); /* Read in the Node name */ 
stmcpy(opname, tempname, (strlen(tempname) - 1)); 
fgets(templine, LINELENGTH, in); /• Read in the property name */ 
do 
{ 

stmcpy(temptext, templine, (strlen(templine) - 1)); 
strcat(temptext, "\n"); 
strcat(nodeproperty, temptext); 
templinelO] = ’\0’; 
for(i = 0; i < MAXLINE; i++) 
temptextii] « ’\0’; 
fgets(templine, LINELENGTH, in); 

I 

while(feof(in) == 0); 

/* Assign c variables to object variables */ 
theOperator = opname; 
theProperty = nodeproperty; 

/* Ver^ the Node exists */ 
theNode = $Node$Lookup(theOperator); 

/* Assign the property to its correct property •/ 
if (stmcmpC'SPECIFICATION", nodcproperty, 13) «« 0) 
i 

theNode.speciflcation « theProperty; 


) 

else if (stmcmpC'IMPLEMENTATION", nodeproperty, 14) «« 0) 

{ 


) 


theNode.implementation = theProperty; 


else if (stmcmpC'CONTROL CONSTRAINTS", nodeproperty, 19) -■ 0) 

{ 
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theNode.controlconstralnts = theProperty; 

) 

else 

{ 

theNode.graphicrecord = theProperty; 

) 

fclose(in): 

} 

protect 

AM_databaseClose(dbname); 

) 


Get Property 

/* Progrsim Get Property */ 

/* This program is used to retrieve a Node property. •/ 

/* It interfaces with the User Interface through two files */ 

/* ddb.in & ddb.out */ 

/* The program reads in the required information from ddb.in */ 
/* then outputs the requested information to ddb.out */ 

/• The required information in ddb.in is */ 

I* Node Name */ 

/* Property Name */ 

/* The information output to ddb.out */ 

/* Property requested */ 


#include <stdio.h> /* include standard C routines */ 
#include <string.h> 

#include "strlng.def /* Include string definitions file •/ 
/* local variables */ 
char opnamefMAXLINEJ, 
tempnamelMAXLINE], 
templine[MAXLINE]; 
char n(^eproperty[MA3STRINGl; 
char temptext[LINEBUFFER]: 

FILE *in, *out; 
int i; 


import $Node; 
maln(argc, argv) 
int argc; 
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char **argv; 


char *dbname: 
char *getenv(): 

obj $Node theNcxie; /• local object variables */ 
obj $Strlng theOperator, 
theProperty; 

if (argc > 1) 

{ 

dbname = argv[l]; 

} 

else if (dbname = getenv("DBNAME")) 

{ 

1 

else 

{ 

printf("Must specify database name, either as a command line 
argument, \nor via the untx environment variable command"); 
exlt(l); 


{ 

AM_databaseOpen (dbname, 0); 
in = fopenC'ddb.in", "r"); 
out = fopenC'ddb.out", "w"); 

fgets(tempname, LINELENGTH, in); /• read in Node name •/ 
stmcpy(opname, tempname, (strlen(tempname) - 1)); 
fgets(templine, LINELENGTH, in); /* read in property name •/ 
/* Assign C variable to object variable */ 
theOperator = opname; 


/* Verify Node exists */ 
theNode = $Node$Lookup(theOperator); 

/* Determine correct property to output •/ 
if (stmcmpCSPECIFICAHON", templine, 13) -= 0) 

1 

/* Assign property */ 
theProperty = theNode. specification; 

/* Convert object type to C type */ 

AM_stringToC(theProperty, nodeproperty, sizeofinodeproperty)); 
/* Output to ddb.out •/ 
fprlntfiout, "%s\n", nodeproperty); 







else if (stxncmpC'IMPLEMENTATION". templine, 14) *== 0) 

{ 

/* Assign property */ 

theProperty = theNode.implementatlon; 

/* Convert object type to C type •/ 

AM_strlngToC(theProperty, nodeproperty, slzeof(nodeproperty)): 
/* Output to ddb.out */ 
fprlntflout, "%s\n", nodeproperty); 

I 

else if (stmcmpC'CONTROL CONSTRAINTS", templine, 19) =** 0) 

{ 

/* Assign property */ 

theProperty = theNode.controlconstralnts; 

/* Convert object type to C type •/ 

AM_strlngToC(theProp)erty, nodeproperty, slzeof[nodeproperty)); 
/* Output to ddb.out */ 
fprintflout, "%s\n", nodeproperty); 

1 

else 

{ 

/* Assign property */ 

theProperty = theNode.graphicrecord; 

/• Convert object type to C type */ 

AM_strlngToC(theProperty, nodeproperty, slzeof(nodeproperty)); 
/* Output to ddb.out */ 
fprlntflout, "%s\n", nodeproperty); 

1 

fclose(in); 

fclose(out); 

) 

protect 

AM_databaseClose(dbname); 


Get Parent 

/• Program Get Parent */ 

/• This program is used to retrieve the name of a Node’s parent */ 
/* It interfaces with the User Interface through ddb.in •/ 

/* & the standard output device */ 

/* The program reads in the required information from ddb.in */ 
/* then pipes the requested information to the standard output •/ 
/* The required information in ddb.in is */ 

/• Child Node Name •/ 

/• The information output to standard output */ 

/• Parent Node Name •/ 
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#include <stdio.h> /* include standard c routines */ 
#include <strlng.h> 

#include "string.def /* include string definitions file */ 
/* local variables */ 

FILE •in; 

char parentnamelMAXLlNEl, 
tempname[MAXLINEl. 
childname[MAXLlNE]; 

import $Node: 

main(argc, argv) 

int argc; 
char ••argv; 

{ 


char *dbname; 
char •getenvO; 
obj $Node theNode, 

parentNode; /• local object variables •/ 
obj $String theChild, 
theParent; 

if (argc > 1) 

f 

dbname = argv[ll: 

} 

else if (dbname = getenvC'DBNAME")) 

I 

} 

else 

{ 

printfC'Must specify database name, either as a command line 
argument,\nor via the Unix environment variable DBNAMEXn"); 
exlt(l); 

} 

{ 

AM_databaseOpen(dbname, O); 
in = fopenC'ddb.in", "r"); 

fgets(tempn8ime,LINELENGTH, in); /• read in Child Node Name */ 
stmcpy(childname, tempname, (strlen(tempname) - 1)); 

/* Assign c variable to object variable */ 
theChild = chlldname; 

/• Verify Node exists */ 
theNode = $Node$Lookup(theChlld); 
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/* Assign Parent Name */ 
parentNode = theNcxle.isChildOf: 

/* Convert to c code */ 

AM_stringToC(parentNode.name, parentname, sizeof(parentname)): 
/• Output to standard output device */ 
prlntfl"%s\n", parentname): 
fclose(in); 

protect 

AM_databaseClose(dbname); 


Get Children 

/* Program Get Children */ 

/* This program is used to retrieve the name of a Node’s */ 
I* Child or Children. It interfaces with the User Interface •/ 

/* through ddb.in & ddb.out */ 

/* The program reads in the required information from ddb.in */ 
/* then outputs the requested information to ddb.out */ 

/* The required information in ddb.in is •/ 

/* Parent Node Name */ 

/* The information output to ddb.out */ 

/* Child Node Name(s) */ 

#include <stdio.h> /* include standard c routines */ 

#include <string.h> 

#include "string.def /* include string definitions file */ 

/* local veiriables •/ 

FILE *in. *out: 
char opname(MAXLINEJ, 
tempname[MAXLINE], 
childname(MAXLINEl; 

import $Node; 

main(argc. argv) 

int argc; 
char **argv; 

{ 

char ‘dboame; 

char *getenv(); /* local object variables •/ 
obj $Node theNode, 
currentNode; 
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obj $Set[obj $Nodel theNodes: 
obj $Strlng theParent; 

if (argc > 1) 

{ 

dbname = argv[l]: 

} 

else if (dbname = getenvC'DBNAME")) 

{ 

} 

else 

I 

prlntfC'Must specify database name, either as a command line 
argument,\nor via the Unix environment variable DBNAME\n"); 
exlt(l): 

} 


I 

AM_databaseOpen(dbname, 0); 
in = fopenC’ddb.in". "r"); 
out = fopenC'ddb.out". "w"); 

fgets(tempname,LlNELENGTH, in); /* read in parent node name */ 
stmcpy(opname, tempname, (strlen(tempname) - 1)); 

/* assign to object variable •/ 
theParent = opname; 

/* verify node exists */ 

theNode = $Node$Lookup(theParent); 

/* assign children names to variable */ 
theNodes = theNode.subNodes; 

/• iterate through the set */ 
iterate(currentNode = theNodes) 

{ 

/* Convert object code to C code */ 

AM_stringToC(currentNode.name, childname, sizeof(childname)): 

/* Output to ddb.out */ 
fprintf[out, "%s\n", childname); 

I 

fclose(ln); 

fclose(out); 

} 

protect 

AM_databaseClose(dbname); 
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Delete Node 

/* Program Delete Node */ 

/* This program is used to delete a Node from the tree •/ 

/* It also deletes any child Nodes coming from the Node */ 

/* It Interfaces with the User Interface through ddb.in */ 

/* The program reads in the required information from ddb.in */ 
/* then deletes the node and all of its* children */ 

/• The required information in ddb.in is */ 

/* Node Name •/ 

#include <stdio.h> /* include standard C routines */ 

#include <string.h> 

#include "string.def /* include string definitions file */ 

/• Local variables */ 
char opnamefMAXLINE), 
tempname[MAXLINEl; 

FILE *in: 
import $Node: 

mainfargc. argv) 
int argc; 
char ••argv; 


char •dbname; 
char •getenvO; 

obj $Node theNode; /• local object variables •/ 
obj $String theOperator; 

if (argc > 1) 

1 

dbneune = argv[ll: 

1 

else if (dbname = getenv("DBNAME’')) 


else 


prlntf("Must specify database name, either as a command line 
argument, \nor via the unlx environment variable command"): 
exlt(l): 


AM_databaseOpen (dbname, 0); 
in = fopenC'ddb.in", "r'j; 

fgets(tempname, LINELENGTH, in); /• read in the node name •/ 
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strncpy(opname, tempneime, (strlen(tempn£une) - 1)); 
/* assign to object variable •/ 
theOperator = opname; 

/* verify node exists */ 

theNode = $Node$Lookup(theOperator); 

/* delete the node by calling the delete operation */ 

$Node$Delete(theNode); 

fclose(in); 

) 

protect 

AM_databaseClose(dbname); 


Traverse Tree 

/* Program Traverse Tree */ 

/* This program is used to traverse the entire tree & */ 

/* produce the PSDL program. */ 

/* It interfaces with the User Interface through ddb.in */ 

/* & ddb.out. */ 

/• The program reads in the required information in ddb.in */ 
/* then traverses the entire tree outputting the contents */ 

/• of all nodes to ddb.out •/ 

/* The required information in ddb.in is */ 

/* Root Node Name •/ 

/* The information outputted to ddb.out */ 

/* for each Node in the tree */ 

/* Node Name */ 

/* Specification •/ 

/* Implementation (Optional) */ 

/* Control constraints (Optioned) */ 

#include <stdio.h> /* include standard C routines */ 

#include <string.h> * > 

#include "string.def /• include string definitions file */ 

/* local variables */ 

FILE ‘in, *out: 
char rootname[MAXLINEl^ 
tempname [MAXLINEl; 

import $Node; 

maln(argc, argv) 
int argc: 
char **argv; 
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char *dbname: 
char *getenv(): 

/• local object variables */ 
obj $Node theNode, currentNode; 
obj ^etlobj $NodeJ theNodes; 
obj $Strlng theRoot; 

If (argc > 1) 

{ 

dbname = eirgvll]; 

) 

else if (dbname = getenv("DBNAME")) 

I 

1 

else 

{ 

printfC'Must specify database name, either as a command line 
argument,\nor via the Unix environment variable DBNAMEXn"); 
exlt(l): 

} 


AM_databaseOpen(dbname, 0); 
in = fopenC’ddb.ln", "r"); 

/• erase the contents of ddb.out */ 
out = fopenC'ddb.out", "w"); 
fclose(out): 

fgets(tempname, LINELENGTH, in); /* read in root node name */ 
stmcpy(rootname, tempneune, (strlen(tempname) - 1)); 

/* assign to object variable */ 
theRoot = rootname; 

/• verify Node exists */ 
theNode = $Node$Lookup(theRoot); 

/• output root node contents */ 

(void) $Node$BuildDisplay(theNode); 

/• Assign children of root to variable */ 
theNodes = $Node$llstSubnodes(theNode),’ 

/* iterate through all the children */ 
iterate(currentNode = theNodes) 

I 


/* output the children node contents */ 
(void) $Node$BuildDisplay(currentNode); 

1 


) 


protect 

AM_databaseClose(dbname); 


81 






Makefile 


The makefile is not a part of the Design Database but is Included 
to assist interested parties in the compilation and execution of the 
DDE. Due to current system memory requirements, the author does 
not anticipate leaving a compiled and working copy of the DDE at the 
Naval Postgraduate School. As stated In Chapter V, each application 
In Vbase requires two megab)rtes of memory. This fact requires that 
the author remove applications once compiled and tested. Therefore, 
the uncomplled programs will remain on the "Suns2" system. The 
following provides the steps to compile and execute the DDE. 

• Obtain a fresh copy of the Vbase Kernel Database. 

• Change directories to the "tdl" directory. 

• Type "tdl -V •.tdl" to compile the tdl definitions. 

• Change directories to the "methods" directory. 

• Type "make appllcatlon_program_name". 

Appllcatlon_program_name is the name of the application program 
to compile, i.e. createRootNode. This command compile the 
COP operations code as well as the application program. Type this 
command until all applications programs are compiled. 

• Type "application program name" to Invoke the application. 

The make file for the Design Database is as follows. 


CEFLAGS= -g 
CLFLAGS = 

CFLAGS = $(CEFLAGS) $(CLFLAGS) 
.c.o:; cop -c $(CFLAGS) $*.c 


LIERARY = -Ivbase -Im -U 
SOURCES = Node.c 

OEJECTS = $(SOURCES:.c=.o) 
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traverseTree: $(OBJECTS) traverseTree.o 
cop $(CFLAGS) -o traverseTVee \ 
$(OBJECTS) traverseTree.o -Ivbase -Im -U 

createRootNode; $(OBJECTS) createRootNode.o 
cop $(CFLAGS) -o createRootNode \ 
$(OBJECTS) createRootNode.o -Ivbase -Im -11 


createChlldNode: $(OBJECTS) createChlldNode.o 
cop $(CFLAGS) -o createChlldNode \ 

$(OBJECTS) createChlldNode.o -Ivbase -Im -11 

storePrc^rty: $(OBJECTS) storeProperty.o 
cop $(CFLAGS) -o storeProperty \ 

$(OBJECTS) storeProperty.o -Ivbase -Im -11 

getProperty: $(OBJECTS) getProperty.o 
cop $(CFLAGS) -o getProperty \ 

$(OBJECTS) getProperty.o -Ivbase -Im -11 

getParent: $(OBJECTS) getParent.o 
cop $(CFLAGS) -o getParent \ 

$(OBJECTS) getParent.o -Ivbase -Im -11 

getChJldren; $(OBJECTS) getChlldren.o 
cop $(CFLAGS) -o getChlldren \ 

$(OBJECTS) getChlldren.o -Ivbase -Im -11 

deleteNode: $(OBJECTS) deleteNode.o 
cop $(CFLAGS) -o deleteNode \ 

$(OBJECTS) deleteNode.o -Ivbase -Im -11 

CLEAN : 

rm -f *.o a.out core traverseTtee createRootNode\ 
createChlldNode storeProperty getProperty \ 
getParent getChlldren deleteNode 
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